Some people are of the opinion that the command line
works one way. You type in a command and hope that you got all of the
information right and received the correct result, which you then have
to interpret. This entire activity sounds quite difficult, somewhat
boring, and error prone to say the least. You have to wonder why
someone would put themselves through all that pain. However, the
command line isn't anything like the scenario just mentioned. Actually,
if you know a few simple rules, using the command line doesn't have to
be hard at all. The following sections describe some of the methods you
can use to work at the command line.
Alternatives to Exclusive Command Line Management
After
you perform the initial Server Core setup, you have several ways to
work with Server Core without using the command line exclusively. One
technique is to create a Remote Desktop connection. Using this
approach, you can use the features of your local client to reduce the
work required at the command line. You can learn more about this
technique in the "Working with the Remote Desktop Connection Application" section of the chapter.
A
second method is to rely on Windows PowerShell. You can't run Windows
PowerShell in Server Core because Windows PowerShell requires a managed
environment. Microsoft is actually working on a smaller version of the
.NET Framework that lacks the graphical features of the full version so
you can run Windows PowerShell in Server Core, but for now, you need to
run Windows PowerShell from the client against Server Core instead of
the local machine. You're limited to using the Windows Management
Instrumentation (WMI) features of Windows PowerShell when working with
Server Core.
The
third method is to rely on the standard consoles that you've always
used. These consoles appear in the Administrative Tools folder of the
Control Panel. Not all of the consoles will work with Server Core and
some of the consoles will have limited functionality. For example, the
Computer Management console shown here contains fewer entries for
Server Core because not all of the entries apply. In addition, when you
select some entries, the console tells you that it can't display the
information. For example, if you click on Performance Logs and Alerts,
Device Manager, any of the Storage features, or SQL Server
Configuration Manager, the Computer Management console will tell you
that these features aren't available.
To
access Server Core from a console, right-click the root node and choose
Connect to Another Computer from the context menu. You'll see a Select
Computer dialog box. Type the name of the other computer (or click
Browse to select it) and click OK. The console makes the connection to
the server and displays its contents. Depending on your network
connection speed and the load on the server, you may notice a
significant delay between actions. Just be patient and the console will
provide the information you need.
|
1. Using Utilities Directly
Generally,
you'll begin using the command line by working with the utilities
directly. After all, it's a little hard to create a batch file or
script if you don't know how the command works. However, using a
command doesn't have to be hard. All you need to remember are two
simple characters, /?. That command line switch says, "Help me!" The command usually will help by presenting you with some options for using it.
Let's begin by working with one of the more useful commands to determine how much of a load the server is carrying. Type TaskList /? and press Enter. Figure 1 shows what you'll see. (I've scrolled back to the top so you can see the major entries.)
The first piece of information is the usage instructions for the command. A set of square brackets ([]) tells you about an optional input. In this case, everything is optional; you can use TaskList by itself.
A slash (/) tells you about a command line switch. Sometimes command line switches appear with a dash (-)
instead. In either case, a command line switch configures the command
to perform a task in a specific way. For example, TaskList doesn't
normally display services, but you can tell it to display services by
adding the /SVC command line switch.
NOTE
Most
command line switches are case insensitive, which means you can type
them in either uppercase or lowercase (or even a mix). A few command
line switches are case sensitive, which means you must type them as
shown. In fact, a few command line switches appear in both uppercase
and lowercase—/A may mean sort in alphabetical order, while /a may mean
to ignore binary information. This book will always tell you when the
command line switch case matters. Otherwise, you can assume that the
command line switches are case insensitive and you can type them using
any case that you wish.
Some
command line switches depend on other command line switches. You'll see
the command line switches nested within multiple layers of square
brackets in this situation. For example, if you want to supply a
password for logging into a remote system to view the tasks running on
it, you must also supply the /System and /Username command line switches.
In
other cases, command line switches are mutually exclusive. The command
line separates these switches with the pipe (|) symbol. The TaskList command won't allow you to use the /M command line switch with the /SVC switch; you must select one or the other.
After
the usage information, you'll normally see a description section for
newer commands. The description tells you what task the command
performs and why you would want to use it. Sometimes this information
is quite complete, as it is with the TaskList
command, and in other cases, you'll still be scratching your head after
you read the description. Older commands don't provide a description at
all; you just have to know what task they perform, which is why many
people don't use them.
A
description of the individual parameters (or arguments and inputs)
comes next. These entries tell you how to use the individual command
line switches. You'll also discover other kinds of information you must
provide. For example, the Dir (directory) command information shown in Figure 2
tells you that you can provide a drive letter, followed by a colon,
followed by a directory path, and ending with a filename specification.
None of these entries is a command line switch, but they're all
important parameters.
The
final section is a list of examples. Only a few commands provide this
kind of information, but it's always helpful when they do. The examples
come in many forms. The TaskList command
provides a list of filters first, so you can see how to get the output
you want. It provides actual usage examples next so you can see what to
type at the command line. The point is that most people could use a
command at the command prompt if they knew the simple /? command line switch. Go ahead and try it out now with the TaskList and Dir commands. You'll want to keep the /?
command line switch in mind as you read about other commands in this
book. Try it out with every one of them and you'll find that most
commands provide some information, usually enough to jog your memory
when you need to use the command.
Storing Commands in Batch Files
I've
worked at the command line for years, so you might assume that I have
all of these commands memorized by now. However, like many people, I
find that memorizing all of the commands, their parameters, and their
command line switches is just too much work. However, discovering the
required parameters one time isn't too much work. That's where batch
files come to my aid. I use batch files to remember specific command
sequences for me.
When
you need to store one or more commands so you don't have to remember
them every time you want to use them, a batch file can do the job. In
fact, you can create batch files that have a limited amount of
intelligence so they don't perform the same task in the same way every
time. Batch files are the first method that many people use to automate
the command line. I have batch files that I wrote over 18 years ago
when I started with computers and I'm still using them today. In short,
a good batch file can last a very long time. The thing to remember
about batch files is that they're very easy to write, only have a
little intelligence (so there isn't any heavy coding), and don't
require anything special to execute.
|
2. Writing Scripts
Scripts
are the next step up in complexity. A script uses a simple programming
language to accomplish tasks. You can't create complex applications
using a script. For example, you wouldn't want to write a word
processor application using a script. However, scripting languages
provide more intelligence than a batch file can. In addition, you can
access some of the functionality that Windows provides. Consequently,
rather than rely on utilities for every action, you can ask Windows for
some help in automating your tasks.
A
script requires a special environment to run. Windows provides this
environment in the form of a script interpreter. The interpreter reads
every line of code you write in your script and performs the task it
requests. Writing scripts is a little harder than writing batch files,
but not nearly as difficult as writing an application with a
full-fledged programming language. Consequently, scripts are exactly
what many people need to automate tasks when they don't want to learn a
full-fledged programming language, yet find batch files less robust
than they'd like.
Most
of the tasks you perform using scripts have standard requirements and
need to execute successfully. Active Directory, the Windows enterprise
database, requires some special handling to work correctly.
3. Scheduling Tasks
No
matter how you work with the command line, whether you use individual
commands, batch files, or scripts, you can schedule a task to run at a
specific time. For example, if you want to defragment your hard drive
every night. Of course, you'd better be certain that
everything is set up correctly before you assume the computer can
perform the task on its own. Many people begin using the Task Scheduler
to run tasks that they could forget during normal work hours and then
progress to after-hours tasks.
4. Relying on Third-Party Utilities
The
tools that Microsoft provides for working at the command line are
basic, simple, and not always the best tools at your disposal. However,
Microsoft is actually spending a lot of time trying to upgrade their
offerings with new features such as the OCList utility provided with
Server Core. Third-party tools for working at the command prompt have
been around for a long time. Most of these products are mature, fully
tested, and quite capable of making your command line experience
everything it should be.